More Related Content Similar to Well-Architectedな組織を
実現するためのチャレンジ - なぜ、CA W-Aを作ろうと思ったのか - #jawsdays 2019 (20) Well-Architectedな組織を
実現するためのチャレンジ - なぜ、CA W-Aを作ろうと思ったのか - #jawsdays 20192. 名前 柘植 翔太 @shotaTsuge
• 所属
株式会社サイバーエージェント
技術本部サービスリライアビリティグループ
• ロール
Senior Organizational Reliability Engineer
• 好きなAWSサービス
AWS Well-Architected Framework
• コミュニティ活動
Japan AWS User Group( - )
3. 名前 柘植 翔太 @shotaTsuge
• 会社での経歴
/ - / Software Engineer @ AmebaPigg
/ - / Infrastructure Engineer
- Ameba Pigg
- Social Game Services
- Curation Media Services
- Streaming Services
- Matching Services
- AdTech Services
- FinTech Services
- And more
/ - Senior Organizational Reliability Engineer
23. インフラ組織としての歩みと課題
• SREとしての活動を始める(2016年〜)
Site Reliability Engineeringの哲学を学ぶ
- Google SREとのディスカッション
- Site Reliability Engineeringに関する書籍の輪読会
- Site Reliability Engineering
- The Site Reliability Workbook
- 以下の4つの分類を中⼼に学んでいった
- Software Engineering
- System Engineering
- Overhead
- Toil
29. インフラ組織としての歩みと課題
• ⾃分達の組織に適⽤する(2018年〜)
Site Reliability Engineeringの哲学を、2つの属性にわける
- System Architecture Reliability
- 横断組織としてサービスの信頼性を担保するロール
- 多種多様なメディアサービス全体の信頼性の底上げをする
- Service Architecture Reliability
- 特定サービスの専任としてのアプローチするロール
- サービスの信頼性の最⼤値を伸ばす
- もっと知りたいという⼈は、 Software Design 年2⽉号 - SRE特集 - を読んで下さい 🙇
でも、現状のSRGの組織状態では、難しいとも感じた
34. OREとは
• 4つの信頼性の層
Corporation(会社) ← IR(Investor Relations)
⇅
Customer(顧客) ← CRE(Customer Reliability Engineering)
⇅
Cooperation(連携)← ORE(Organizational Reliability Engineering)
⇅ ↑横断組織だからこその必要性💪
Service(サービス) ← SRE(Site Reliability Engineering)
38. AWS W-A について
• AWS Well-Architected Framework(AWS W-A)とは
AWSをユーザ向けに10年以上に提供した上で得られた経験を元に、
提供してくれているシステム設計‧運⽤の “⼤局的な” 考え⽅とベストプラクティス集
AWS W-Aの構成要素のホワイトペーパーや確認質問集も定期的に更新されている
AWSのソリューションアーキテクト(AWS W-A認定パートナー)も構成要素に含まれている
最近では、AWS Well-Architected Tool も発表され、セルフチェックをすることも可能に
2018/02時点では、⽇本語対応はされていません
39. AWS W-A について
• ホワイトペーパーについて
5つの柱(ホワイトペーパーの構成)
- 運⽤の優秀性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
※ 2019/02時点
最近では…
IoT や Serverless 向けのホワイトペーパーも出ている
より詳しく知りたい⼈は、公式サイトを⾒てください
40. AWS W-A について
• よくある誤解
AWS W-A をやればええ感じに出来ると思っている
あくまで設計 “原則” なので、実装の詳細やアーキテクチャパターンは扱っていない
AWS W-A は、銀の弾丸ではない!
監査(Audit)的な使い⽅が出来ると思っている
現状を知るのには使えるが、監査的な使い⽅は望ましくない
AWS W-A をすれば OK ではなく、そこからどうやっていくかを⼀緒に考えることが⼤切
ガバナンスのインプットには使えると思っている(個⼈的⾒解)
⼀回やればOKだと思っている
AWS W-A は定期的に実施する必要がある
AWS W-A のフロー(チェック‧改善)を継続的にまわすことが重要
41. AWS W-A について
• もっとAWS W-Aを知りたい⼈におすすめの資料
AWS Black Belt Online Seminar & 公式ドキュメント(英語)
42. AWS W-A について
• 実際に AWS W-A を試してみて
AWS W-Aを試してみた、サービスの⼈からの意⾒👂
- 運⽤周りのヒントをもらったので、それをもとに改善していこうと思えた👍
- どういったセキュリティリスクがあるかを認識することができた👍
などのポジティブな意⾒をもらいつつも…
⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、
弊社担当のソリューションアーキテクトによる実施の話になります。
43. AWS W-A について
• 実際に AWS W-A を試してみて
AWS W-Aを試してみた、サービスの⼈からの意⾒👂
- 複数項⽬からの選択式なので、項⽬によっては回答が難しい
- 実際に課題は分かったけど、事業レベルでどう改善を進めていけば良いかわからない
- 定期的にセルフチェックしたい
という声も、多数ありました。
また、弊社ではAWS以外のプラットフォームも活⽤しているので、
同じ様なアプローチが出来ないかと思うようになり、
プラットフォームに依存しない Well-Architected Frameworkを作ることにしました。
⚠ ⾃分達の組織が試す段階では、AWS Well-Architected Tool は発表されていなかったので、
弊社担当のソリューションアーキテクトによる実施の話になります。
45. CA W-A について
• CA Well-Architected Framework(CA W-A)とは
- AWS W-Aを元に作成した、プラットフォームに依存しない汎⽤的なフレームワーク
- 質を落とさないようにしつつ、回答のハードルを下げる
- 複数項⽬からの選択式ではなく、Yes/No だけで判定できる⽅法を採⽤
- 回答しづらい項⽬は削除するなど、質問数を可能な限り削減
- 内製だからできるカスタマイズ
- Google App Script で⾃動集計 & 解析や Slack 通知を実施してくれる Bot を⽤意
- ヒアリングシートの管理 & 運⽤を⾃動化
- Review Report(レビュー結果)の Suggestion
- 社内ナレッジを適切に共有することが可能
46. CA W-A について
• ⼤枠は、AWS W-Aと同じ5つの柱
合計75の項⽬を回答することにより、現状のサービスの状態を紐解く
- Security
- Reliability
- Performance
- Cost Optimization
- Operations
47. CA W-A について
• サービスの今を⾒つめ直すための新たなライフサイクルを⽣み出す
学習
Condition Review
測定
Condition Review
改善/事業貢献
Improvement
コミュニケーション
Review Report
Discussion & Planning
48. CA W-A について
• 実際に、CA W-Aを試してみたサービスからの声
- AWS以外のプラットフォームでも⾏えるのは嬉しい
- 現状のサービスが抱えている潜在的なリスクの可視化ができる
- 現状課題に対して、事業部全体で共通認識を持てる
- 事業部にとって何をすればいいのかを考えるときの資料として活⽤できる
- 社内に存在するナレッジを活⽤できるようになる
- 知らなかったことを知れたり、それによる議論などが⽣まれる🗣
50. CA W-A の実施フロー
CONDITION REVIEW
事前にサービスの
コンディションチェック
START
REVIEW REPORT
ORE とサービスの技術責任者で
2時間レビュー会を実施
DISCUSSION & PLANNING
事業責任者 & 技術責任者と
課題の認識合わせ
60. IMPROVEMENT
• どうやって改善を進めるのか
Review Report の Suggestion が重要になる
組織として持っているナレッジ(ベストプラクティスやモジュールの提供など)を
効率的に提供する為に、複数サービスでのCA W-Aレビューの結果をもとに、
傾向的に早く提供した⽅が良いものから準備を進めている
どういった Suggestion をしてるのか
- ベストプラクティス集
- ECS, CI/CD
- Terraform の共通モジュール
- Ansible の共通 Playbook
- オペレーション周りの⾃動化ツール
- and more
61. IMPROVEMENT
• CA W-Aとは何なのか?
CA W-Aは、コミュニケーションツールだと考えています🤝
ただ、チェックするのが⽬的ではなく
技術から事業成⻑を促すためのコミュニケーションツール💪
として考えています
CA W-Aについて、もっと詳しく知りたいという⼈は、
CA BASE CAMPという社内カンファレンスに登壇した資料を後⽇アップ予定なので、
是⾮それを⾒てください🙏
66. OREの今後について
• CA W-Aは、始まりに過ぎない
横断的なアプローチなので、 System Architecture Reliability の要素が⼤きい
• 我々がやるべきことは、まだ沢⼭ある
サービスの信頼性の最⼤値を伸ばす、 Service Architecture Reliability 的な
アプローチをいかに実践していくかが⼤事
ビジネスKPIに紐づくSLI/SLOの策定と計測をサポートする為のフレームワークも作成予定
そのために、SRGに所属するインフラエンジニア を適切なロールに細分化することも
考えています。
73. Special Thanks
• JAWS DAYS Stuff 🙇
本当に感謝しかないです🙌
• ORE Team
Shonosuke Okada(@rm_rf_slant)
• AWS Well-Architected Team and Japan AWS Team
いつも⼤変お世話になってます🙌